What's New

A new Searchable Drop List Element has been included in this latest release of Digitise Forms. Building on the functionality of the standard Drop List Element, the Searchable Drop List provides automatic filtering of drop list contents, allowing users to quickly locate an item from within a long list of items by applying one of the Element's Filter options (i.e., StartsWith, Contains, or EndsWith).

Configured in a similar way to the standard Drop List, a form which currently uses the standard Drop List can easily be updated by swapping it for the Searchable Drop List, improving the form's usability and enhancing its performance.

This latest version of Forms now supports more advanced web server configurations by allowing forms to be accessed by including a port number within the Server URL option within the Publishing Profile.

With Forms v2.0, there have been performance-improving updates to several Elements including the Charts, the Toast Notification, the File Upload, and the Progress Bar. The updates mean that these Elements will load more quickly - especially where forms which use them are accessed using low-powered mobile devices, or where a slow internet connection is being used.

Advanced Element developers can now include various controls within customised Elements without having to program the controls themselves. This is achieved using a library of predefined controls called the Syncfusion control framework, and provides the following controls:

• Chart
• Slider
• Toast Notification
• File Upload
• Progress Bar
• Drop List
• Searchable Drop List
• Schedule

Where forms that have been created in older versions of Digitise Forms, and its predecessor, FX, are opened in Form Studio and are subsequently updated in a newer version, a migration of the form's custom JavaScript is sometimes required.

With Forms v2.0, improvements have been made for when this migration takes place. Previously, when upgrading a form's custom JavaScript, some references to Elements' '.text' properties were wrongly converted to '.value'. This issue has now been fixed.

Improved timeout handling and behaviour has been incorporated into this latest release of Digitise Forms. The duration of a Form Server session can now be set within a form's Profile Settings using the new Maximum Session Length (minutes) option. This option lets you control the length of time that a form will remain active, which you can adjust according to how long you think it will take users to complete the form.

When the time period specified in the Maximum Session Length (minutes) option has expired, a new message box will appear, giving you the option to start a new session. Starting a new session will allow you to retain any information already entered on the form, and to continue entering or selecting data. A new topic - Form Timeouts - dedicated to timeout functionality has also been written, which includes general guidance on setting timeout periods.

The new Form Timeouts topic also covers how to set both IIS Idle and IIS Recycling/Refresh timeouts. Although not as impactful as Form Server timeouts, IIS-related timeouts can still, in some situations, cause an IIS session to end while a form is being completed. By following the steps outlined within the Form Timeouts topic, you can configure when IIS-related timeouts will occur, reducing the chances of a form becoming temporarily unresponsive when the current IIS session ends and a new one begins.

Two new flooding prevention settings - Maximum Request Period (minutes) and Maximum Requests allowed - aimed at stopping someone from loading a form a large number of times in a short time period have been added to the Security Category of the form's Profile Settings. In previous versions of Digitise Forms, these could only be accessed from within Form Manager, but the settings are now configurable both within Form Manager and within Form Studio.

In Digitise Forms version 2.0, the following changes have been made to the way in which PDF copies of forms are created and accessed:

• PDFs are now no longer saved in the NDLFXPDF database, but are saved in the NDLFXFile database instead. This deploys the same mechanism as the one used for file uploads.
• Non-GUID The acronym for 'Globally Unique Identifier', a GUID is a 128-bit string used to identify an object such as a Primary Key within a database table, that no other object on any system is likely to have. Primary Keys can now be used for PDF records.
• PDFs can now contain data submitted to multiple tables, including imported tables.

To support the recent changes, a dedicated Migration Guide for PDF Generation and Access topic has been created. The topic contains a summary of the changes and discusses how they might impact your current processes. It also offers guidance on the steps that you may need to follow in order to upgrade your processes to make use of the new functionality.

In previous versions of Digitise Forms, if you wanted to save a PDF copy of a completed form to a SQL database, you could only achieve this if the form dataset that the PDF was created from contained a GUID The acronym for 'Globally Unique Identifier', a GUID is a 128-bit string used to identify an object such as a Primary Key within a database table, that no other object on any system is likely to have. Primary Key. This meant that datasets that contained non-GUID Primary Keys (for example, integer Primary Keys), were unable to use this functionality.

Saving a PDF to a database is now more flexible, allowing non-GUID Primary Keys to be used. Where possible, we would still recommend using the more secure GUID data type as a Primary Key if you intend saving a PDF version of your form to a SQL database, but this is no longer a prerequisite (see the Create and Manage Datasets topic for more information on Primary Keys and GUIDs).

This version includes a change which affects the way PDF copies of completed forms are stored, and which transitions the saving of PDFs from the NDLFXPDF database to the NDLFXFile database. Now, when you opt to save a PDF in the database, the NDLFXFile database is used, rather than the NDLFXPDF database. This utilises the same saving mechanism as that used for storing uploaded files.

See the Migration Guide for PDF Generation and Access topic for more information.

Forms that contain data submitted to multiple datasets can now generate PDFs. This allows for PDF generation for more complex forms, where, for example, one dataset is created by Forms, while another is imported from SQL.

A new Retain Request Data option has been included in the form's Profile Settings, which replaces the previous Store Request Data option. In previous versions of Digitise Forms, where you wanted to create a PDF copy of your form, the Store Request Data option (along with the Is Visible in PDF option) had to be selected in order for Elements and any mapped and/or entered data to be included. This is now no longer the case. The appearance of items within the PDF is now governed solely by the Is Visible in PDF option.

The new Retain Request Data option is used to allow you to choose to store Elements and any mapped/input data so that a PDF copy of the form can be created using those Elements and data later on - for example, once the form has been submitted and it has been closed.